先講清楚：模式跟規模是兩件事

這裡有個容易混淆的地方，我自己也繞了一陣子才理順。鼠勾以同時在判斷兩個維度，它們互相獨立。

一個是模式，管的是「這個人帶著什麼東西進來」：

• A 探索：什麼都沒有，腦袋裡只有一個想法，要從零開始問。
• B 整理：手上有素材（會議記錄、信件、簡報、一段口頭描述），要先把素材吃進去，再補沒講到的地方。
• C 更新清單：上次聊完拿了一份待確認清單，這次把答案填回來。
• D 健檢：已經有一份寫好的需求文件，想知道它哪裡不夠完整。

另一個是規模，管的是「這個需求有多大」：小功能走快速模式只談 3 個面向，中型走標準模式談 7 個，大型專案走完整模式談 8 個（多一塊非功能性需求）。

模式決定從哪裡接手，規模決定要問到多深。一個走 B 整理的需求可以是小功能，也可以是大型專案。把這兩件事拆開之後，整個判定邏輯才理得清楚。

模式判定：能推斷的就不要問

後來的版本把那個四選一選單拿掉了大半。原則改成：能從使用者的行為直接推斷的，就不要開口問。

最明顯的訊號是有沒有上傳檔案。

使用者一開場就上傳檔案，模式其實已經可以判斷出來，不需要再問一次。鼠勾以會先讀那個檔，判斷它屬於哪一類：

%%{ init: { 'flowchart': { 'curve': 'linear' } } }%%
flowchart TD
    A[使用者上傳檔案] --> B{這是什麼文件?}
    B -->|已寫好的需求書/規格書| C[導入 D 健檢]
    B -->|上次的待確認清單| D[導入 C 更新清單]
    B -->|會議記錄/信件/簡報/草稿| E[B 整理: 先提取再補完]
    C --> F[算 SA 就緒度, 列缺漏]
    D --> F
    E --> F
    F --> G[進問答: 已提取的跳過, 只補沒講到的]

判斷檔案用途這一步是關鍵。一份排版整齊、章節分明的東西，大概是「已經寫好的需求」，那就走健檢；一份滿是 [必確認]、[可預設] 標記的清單，那是上次的產物，走更新；剩下那些零散的會議記錄、轉貼的信件、半句話的描述，就是 B 整理的原料。

只有當使用者什麼都沒帶、純文字描述一個想法時，才是 A 探索，這時候才老老實實從區塊 1 開始問。

整理模式的精髓：別讓人重講一遍

B 整理是這四種裡最值得細講的，因為它最能體現「不浪費使用者時間」這個原則。

這個情境的問題很具體：使用者把一份開了 90 分鐘的會議記錄貼進去，裡面背景、目標、功能都寫得很清楚，工具卻還是從「請問你這個需求的背景是什麼？」開始逐題問。那份檔案等於白貼。

所以鼠勾以拿到素材的第一件事是「提取」，把檔案內容拆進各個區塊，然後攤開來給你看：

我看了你上傳的檔案，整理如下：
檔案摘要：健身 App 的個人化內容推薦功能
需求規模：中型功能
各區塊提取結果：
區塊 1 專案背景 — 已提取
區塊 4 功能範圍 — 已提取
區塊 5 業務流程 — 只提到一部分
區塊 7 例外情境 — 沒提到
以上判斷正確嗎？或你想調整？

已經提取到的區塊，後面只做「總結確認」，不再逐題問。沒提取到的，才進入問答。等於是把這個人已經做過的功課認下來，只補真正的空白。

這裡有個我刻意守住的紅線：就算提取出來的東西看起來已經很完整、分數也不低，鼠勾以也不會自動跳去產出文件。它會提醒你還有哪幾塊沒補，把剩下的補完才整理預覽。要不要現在就出文件，是你說了算，工具不替你決定「夠了」。

健檢模式：先量完整度，再決定補哪裡

D 健檢的定位跟整理很像，差別在輸出。整理的重點是「幫你把需求做完」，健檢的重點是「告訴你這份需求現在幾分、哪裡破洞」。

它會從 7 個面向掃一遍完整度，額外檢查有沒有端對端流程圖、畫面清單、使用者畫像、個資風險評估、修改歷程這些東西，然後產出一份報告：哪些寫得好，哪些要補，附上就緒度分數和一份待確認清單。

報告給完，它會接一句：

需求中有 4 個待補充項目。要不要我來引導你逐一補完？

缺得少就建議快速模式，缺得多就走標準或完整。使用者同意的話，就直接接進整理流程，已經寫清楚的區塊一樣跳過。健檢的結果會導向下一步，而不是停在一份報告。

吃進來的文件，長得跟模板完全不一樣

匯入這條路還有一個坑，是很後來才踩到的。

有次我拿一份 25 章的規則書丟進去測。那份文件是別人寫的，章節編號自己一套，沒有 Feature 詳細規格，畫面清單也不是我們那幾欄的格式，整份就是一條一條規則平鋪下來。鼠勾以照樣把內容提取得好好的，從頭到尾沒提過一句「這份結構跟我這邊不一樣」。

問題出在後面。這份需求最後要交給 RD 開發，格式得統一，可是模型剛吃完一份 25 章的扁平規則書，產出的時候很容易照著它剛讀到的結構走，於是吐出來的也是一份扁平規則書。

修法分兩段。產出那端本來就有一條規則：出文件前要重新載入模板骨架，以模板為唯一權威逐格填，不拿前文段落或匯入文件的章節結構當基準（這條規則怎麼來的，Day 26 講自檢時會再提）。但那只保住了出口，入口完全沒有人把關。

所以匯入的當下多做一件事：提取內容的同時，順便比對來源的章節結構跟 PRD 模板差多少。對不上就在提取摘要裡直接講：

這份文件的章節結構跟標準模板不同（自訂章節編號、缺 Feature 詳細規格）。我會重新對應到標準模板，不照抄來源章節。

講完照做，不另外問一次。這裡我猶豫過要不要停下來讓使用者選「照你的還是照模板」，最後選了主動告知加直接重整。會走匯入這條路的人，手上通常就是一份格式很亂的舊文件，他要的是有人幫他整理成能用的樣子，不是再被問一次格式偏好。

如果丟進來的是會議記錄、信件那種本來就沒有既有結構的素材，這步就跳過。健檢模式則多掃一項「結構符合度」，符合或不符合直接寫進報告。

更新模式的一個 bug：明明該停下來問，它卻自己交卷

C 更新清單這個模式，後來被我抓到一個矛盾。

它的情境是，使用者上次聊完拿了一份待確認清單，裡面幾個 [必確認] 還沒解決，這次回來把答案填上。我最早給的規則是「所有 [必確認] 補完，就進入最終產出」。那時候覺得理所當然，東西都補齊了，當然出文件。

可是我在整理模式那邊定的規矩是反過來的。前面講整理模式時提過那條紅線，內容看起來再完整也不自動產出，要不要出由使用者決定。兩個模式的行為對不起來，一個會自己往產出衝，一個會停下來問。使用者這次用更新、下次用整理，大概會覺得這工具有時候很自作主張、有時候又很客氣。

後來我把更新模式也改成停下來問一句：那幾項都補好了，要現在整理成文件，還是再看看別的地方。

這種矛盾最難抓，每一處單獨看都沒有問題，要兩處擺在一起才看得出來。我會發現它其實是偶然：那天在查另一件事，順手把所有會觸發「產出文件」的規則拉出來排在一起，才注意到更新模式那一條跟其他的寫法不同。這也是 Day 8 提過的規則漂移，規則散在不同檔案各改各的，時間久了就會互相牴觸。

把這四種模式攤開來看，背後其實是同一個信念：判斷規模、判斷文件類型、判斷該跳過哪些題，這些都是工具該扛的活，不該變成使用者進門前的考試。使用者只要把手上有的東西丟進來就好，剩下的鼠勾以自己接。

明天聊產出前的最後一關：文件組裝完之後，它怎麼自己把整份 PRD 再交叉檢查一遍，才敢拿給你看。

這是 iThome 鐵人賽系列文章。明天見。